Exchange 2010 : Managing Exchange Recipients (part 1)

EMS has been designed to allow automation of repetitive administrative tasks and it's a best practice to become very familiar with how EMS can be utilized in your Exchange organization. EMS is used to manage your Exchange Recipients and provide detailed control over these objects.

In addition to the EMS and the EMC, Exchange 2010 now includes the ECP as mentioned earlier in this chapter. The ECP gives both administrators and end users the ability to perform a variety of management tasks through a Web-based interface. Administrative tasks that can be completed in ECP include managing mailboxes, contacts, groups, and User and Administrator roles.

Exchange 2010 SP1 provides a number of improvements in ECP for both users and administrators. The user improvements include:

• Users can modify calendar sharing permissions management.

• Users can better identify their POP/IMAP/SMTP server names.

The ECP improvements for administrators include:

• Support for administrators that do not have a mailbox-enabled account to log on to ECP

• Additional RBAC features, including being able to create, assign, and modify user roles

• Exchange ActiveSync policy, reporting, and device management

• Per-User Mailbox settings

• Improvements to the Message Records Management retention tagging

• Ability to define a group-naming policy

What are Exchange Recipients? In any messaging system, some Active Directory objects are mailbox-enabled or mail-enabled. These objects are referred to as Exchange Recipients. Exchange Recipients include:

• User mailboxes A user mailbox is a mailbox assigned to an Active Directory object that can represent a person who uses the network. Each user in Active Directory can be mailbox-enabled, mail-enabled, or neither. Each user's mailbox is a private area that allows an individual user to send, receive, and store messages.

• Room mailboxes A room mailbox is an Active Directory object that can be used to manage meeting rooms such as conference rooms, training rooms, or any location where you want scheduling to occur so as to prevent double booking.

• Equipment mailboxes These types of mailboxes are also Active Directory objects. Equipment accounts have the user account disabled and are used for items such as company cars for travel, projectors, or loaner laptops.

• Linked mailboxes This type of mailbox is accessed by an external account. This comes in handy if an organization has many resources and needs to consolidate them into a resource forest for a simplified management solution.

• Contacts These are Active Directory objects that contain information about a person or an organization outside of your Exchange organization. These objects can appear in distribution groups and the Global Address List (GAL).

• Mail-enabled distribution and security groups A mail-enabled Active Directory security group object can be used to grant access permissions to Active Directory resources as well as to distribute messages to multiple recipients. You can use a mail-enabled Active Directory distribution group object to distribute messages to a group of recipients.

• Dynamic distribution groups A dynamic distribution group uses a recipient filter and conditions to determine its membership at the time messages are sent.

1. Managing Mail-Enabled Users and Mailboxes

Mailboxes and mail-enabled users are Active Directory objects that contain information about users and also provide credentials to log on to the organization and access resources. Being able to use the credentials to access resources is one of the major differences between a mail-enabled user and a mail-enabled contact. Many tasks are performed when managing user mailboxes, including the following:

• Creating mailboxes

• Adding an e-mail address for a user mailbox

• Creating a linked mailbox

• Connecting a mailbox

• Configuring anti-spam

• Deleting mailboxes

• Disabling mailboxes

• Configuring mail forwarding

• Configuring message size limits

• Configuring storage quotas

• Updating recipient's information

Many of these tasks are fairly straightforward and often control what best practices should be—such as using the New Mailbox Wizard—some attention should be given when managing and designing an Exchange organization. The next several sections touch on a few of the major tasks that are performed on a regular basis.

1.1. Creating Mailboxes

The New Mailbox wizard guides and prompts you through the entire process of creating a new mailbox or mail user. However, thought must be given to naming conventions and also to the database where the mailbox will reside.

When determining user and display name, best practice is to use a convention that occurs if you have several users that have the same first name or last name. Often a naming convention that includes a combination of first initial and last name or first initial, middle initial, and last name will help avoid many possible user name issues when users have the same first or last name. A mailbox alias should follow the same standards because these can be used with Outlook and OWA to find user information. In Exchange 2010 SP1, the New Mailbox Wizard no longer requires a mailbox alias to be typed in manually. The wizard will derive the alias from the other information you have entered. In large companies, numerous people have the same last name, such as Smith. If the naming convention is to use the first initial and the last name, both Jeff Smith and John Smith might assume their user name and alias to be jsmith. One solution is to use the first two letters of the first name so that the aliases in this case would be jesmith and josmith. Again, a large organization might have many employees whose names start with the same two letters. To alleviate this potential problem, some companies use numbers. Thus the first alias in our example would be jsmith01 and the second would be jsmith02. This convention allows up to 99 people with the same first-name initial and last name. In companies that support multiple languages or have employees in multiple countries, consideration must also be given to extended character sets, local naming customs, and the likelihood of users having similar names.

Some companies even choose to not have a standard naming convention; instead, aliases are based on some combination of the first, middle, and last name. This would mean that Jeff Smith might be jeffs, jeffsmith, jesmith, or jeffsmi depending on which alias is available. There are a couple of very good reasons to use this method. One reason is that an outside user cannot assume that Jeff Smith's alias is jsmith and try to send an e-mail to [email protected] to get in touch with him. This also provides a fair way to distribute aliases.

Choosing a database for the mailbox to reside on also requires some thought.  Separating mailboxes into multiple databases is a recommended practice that provides the following benefits:

• Decreases the time to restore a database from backup because each database is smaller

• Reduces impact on the Exchange environment if a database goes offline because each database has fewer mailboxes

• Allows you to separate your users based on conditions such as mailbox size, organization divisions, or titles

• Allows for simpler mailbox limit and deleted item retention management when all users in the same database share the same configuration

Creating separate databases will reduce the time needed to restore because you will have more and smaller databases: The smaller the database, the quicker the restore will be. This can allow an organization to return the affected users to service more quickly. It will also reduce the impact on the organization if you lose a single database because it will only affect those users in the offline database instead of the entire organization.

All Exchange environments see a mix of users when it comes to mailbox sizes. Separating mailboxes based on size, service levels, or user location into different databases is the way many organizations choose to handle mailboxes. This usually makes capacity planning easier and helps to ensure that varying SLAs can be met. For example, Fabrikam has 100 mailboxes with 5-GB limits that have an SLA that only allows for 1 hour of downtime each year, whereas all of the other mailboxes have an SLA that allows for up to 4 hours of downtime a month. To help meet the higher SLA, the Fabrikam IT department decided to create 10 mailbox databases, each with 3 current mailbox database copies and 1 lagged database within the DAG. All of the other mailboxes are deployed with only two additional copies and are backed up using backup software. This has allowed Fabrikam to provide two levels of services that require significantly different functionality.

Another way to approach this problem is to randomly assign the different-sized mailboxes and those with different SLAs across the available mailboxes. This way fewer of the same users are affected.

In a perfect world the mailbox sizes would remain less than 1 GB and thus ease administrative efforts; however, this is not realistic. It is very hard to convince an organization's vice president that she must delete her e-mails and attachments to remain under a mailbox limit, and she would be equally annoyed to receive an e-mail alert every day telling her to do so. Creating a separate database for executives will allow for a different policy set to apply. Each organization is different and some will only need a few databases. Other organizations will require more. Carefully plan how these mailbox databases will be divided.

1.2. Managing Mailbox Permissions

In some instances you may need to grant permissions to a mailbox. The user can do this by assigning a delegate within Outlook using the Delegates feature. This will allow a user to give another user access to his mailbox resources. This is done to the manager's mailbox to allow an assistant to manage e-mail and appointments. Delegate access also gives the delegate the ability to send e-mail messages on behalf of the mailbox holder. Delegation can also be configured to allow access to specific folders within the mailbox, as shown in Figure 1. Administrators can also set permissions within a mailbox by using the Set-MailboxFolderPermission cmdlet. This is especially helpful for users that may not have access to Outlook, or that may rely on assistance from the Exchange administrator.

An administrator can also modify permissions by granting Send On Behalf, Send As, Receive As, or full mailbox permissions to an entire mailbox. This allows users other than the mailbox owner to send or receive messages as if they were sent by the mailbox owner. Setting these permissions may be necessary to support a third-party application that sends or receives e-mail messages to and from users. Keep in mind that it can take up to 120 minutes for permission changes to be loaded into the cache Exchange uses to control mailbox permissions. If the mailbox is hidden from the address list the user will not be able to select the hidden mailbox to send from within the GAL. To manage the Send As permission with the EMS you can run the Add-MailboxPermission cmdlet. For example, to give Joe permissions to send as Ed, you would run Add-MailboxPermission "Ed" -User Joe -Extendedrights "Send-As". The Send As right gives the user access to send e-mail as if he was sending it from the mailbox they have the permissions on. Additional rights, including Receive As, can be assigned using the Add-MailboxPermission cmdlet. For more information, see http://technet.microsoft.com/en-us/library/bb124097.aspx.

You can also set permissions on Exchange objects using Add-AdPermission to provide broader permissions. For example, you can give permissions to an entire database. This is especially helpful when granting permissions to a service account. To give ServiceAccount rights to all mailboxes in the DAG01DB1 database, you would run Add-AdPermission -Identity DAG01DB1 -User ServiceAccount -ExtendedRights Receive-As. It is important to remember that the EMC does not provide an option to manage Receive As rights or to assign permissions to an entire database. In these cases you need to use the EMS. The Receive As permission allows a user to be able to read all e-mail items in the mailboxes that the permission is assigned to. For more information on how to use Add-AdPermission, see http://technet.microsoft.com/en-us/library/bb124403.aspx.

You can also assign full access permissions, which allow a user to be able to open and modify mailbox contents as well as send e-mail on behalf of the mailbox. Full access rights are applied to the mailbox and not to a database; therefore, you use the Add-MailboxPermission cmdlet or the EMC Manage Full Access Permission Wizard. For example, to grant Ed full access to Joe's mailbox you can run Add-MailboxPermission Joe -User Ed -AccessRights FullAccess.

1.3. Deleting Mailboxes

At some point a user will leave the company and her mailbox will be disconnected or deleted. Plan ahead of time how you will handle disconnected mailboxes so that they are neither deleted too soon nor remain too long. Getting rid of these mailboxes too soon can lead to the accidental destruction of needed information; keeping mailboxes too long can eat up disk space unnecessarily.

Deleting or removing a mailbox differs from disabling a mailbox in that deleting it disconnects the mailbox from its associated user account and removes the user from Active Directory. Exchange has a default retention of a deleted mailbox of 30 days, which allows for the user to be reconnected to the mailbox. This is useful in case the user decides not to leave or the company decides to retain him. If you determine that the mailbox is no longer needed but you wish to retain the user's Active Directory account, the mailbox should be disabled. Disabling a mailbox might be necessary if an employee goes to different position in the company where company e-mail is not required but the employee still needs to log on to the network each day to fill out reports or other organization-related tasks. To use the EMS to disable mail for a mail-enabled user, run the following cmdlet:

Disable-MailUser [email protected]

It is recommended that you leave the default 30-day retention period. Choosing not to reduce this retention period can result in having to restore the entire database to recover the mailbox. Any mailbox that is deleted is only marked for deletion during the retention period. This is similar to the Windows Recycle Bin, in which the items are not actually deleted until the Recycle Bin is emptied. A deleted Exchange mailbox is automatically deleted or emptied after the retention period. If you want to permanently remove the mailbox immediately, you can do so using the EMS by running the cmdlet Remove-Mailbox Kelly -Permanent.

1.4. Disconnected Mailbox Management

After deleting a mailbox you might determine that the mailbox or data within it is still needed. During the deleted mailbox retention period the mailbox can be reconnected to an Active Directory user account that does not already have a mailbox associated with it. Both the EMS and the EMC can be utilized to reconnect a disconnected mailbox. Under the Recipient Configuration node in the Console tree of EMC, the Disconnected Mailbox folder allows an administrator to connect to the Mailbox server and run a wizard to reconnect the mailbox.

You can also use the EMS to reconnect a disconnected mailbox. To retrieve a list of disconnected mailboxes on Fresno-EX01 run Get-MailboxStatistics -Server Fresno-EX01 | where { $_.DisconnectDate -ne $null } | select DisplayName,DisconnectDate. You can then reconnect the mailbox using the mailbox GUID while running Connect-Mailbox -Identity DeletedMailboxGuid -Database MailboxDatabase1 -User NewUserName.

Note that if the mailbox retention period has passed or you have used Remove-Mailbox with the Permanent switch, you will not be able to reconnect the mailbox. In this case you might have to restore the mailbox from a backup before you can access the deleted mailbox data.